Here are the 10 usual suspects (and what to do) when a 2110 plant misbehaves:

1. PTP mismatch (domain/E2E–P2P/one-step–two-step)
• Symptom: Slaves never lock; GM flaps. (network keeps switching which clock is the GM)
• Fix: Standardize one domain, one delay mode (E2E or P2P), one step mode plant-wide.

---

2. PTP not prioritized (QoS wrong)
• Symptom: OffsetFromMaster jumps when media ramps up.
• Fix: Mark PTP CS6 (or your top class) → LLQ/strict queue on every port; no WRED/policers on PTP.
  LLQ (Low-Latency Queuing) is a QoS feature that gives selected traffic a strict-priority queue, letting those packets jump to the front of the line to minimize delay and jitter (e.g., for PTP or voice), typically with policing so it can’t starve other queues.
  
  WRED (Weighted Random Early Detection): A queue congestion-avoidance method that randomly drops some packets before the buffer is full to signal TCP flows to slow down. Great for bulk TCP; bad for real-time UDP/PTP because it creates unpredictable loss/jitter.
  2110 tip: Never enable WRED on the PTP (LLQ) queue; usually keep it off for media queues too.
  
  Policers:Rate enforcers that cap traffic at a configured rate (CIR/PIR). Packets above the cap are dropped or remarked immediately (no buffering/smoothing). Useful to contain misbehaving senders or protect the fabric at ingress; don’t police the PTP class.
  
  Contrast with a shaper, which buffers and smooths to a target rate instead of dropping.
  
  Quick 2110 defaults:
  PTP = strict-priority LLQ, no WRED, no policer.
  Media queues = high priority, typically shaped (not policed), WRED off.
  Best-effort/control = moderate priority; WRED/policers only if you truly need congestion control.

---

3. Inconsistent DSCP→queue mapping
• Symptom: Works on some switches, not others.
• Fix: Make the same map everywhere; verify with per-queue counters. (Example here).

---

4. Transparent/Boundary clock misuse
• Symptom: CorrectionField stays 0 (TC off) or stepsRemoved grows too large (BC chains).

• Fix: Small L2 → P2P TC everywhere. Larger/mixed networks → BC at agg/leaf; keep stepsRemoved ≤ ~3.
  
  Agg = Aggregation (or spine/aggregation) switches: uplink/core layer that all the leaves connect to; they aggregate traffic, often run routing, PTP BC roles, ECMP, etc.
  
  Leaf = access/edge switches: where endpoints (cameras, gateways, servers, multiviewers) physically plug in; they connect northbound to the agg/spine.
  
  In a 2110 plant: leaves host media devices; aggregation handles high-speed interconnect, multicast routing (if used), and often PTP Boundary Clock; keep Red/Blue fabrics symmetric across both layers.

---

5. Multicast control broken (IGMP/PIM)
• Symptom: Random black frames, missing audio, joins/leaves slow.
• Fix: IGMPv3 snooping + querier at L2; PIM-SSM at L3; use 232/8 groups; enable fast-leave.
  
  L2: IGMPv3 snooping + querier (and fast-leave)
  IGMP snooping (on switches): The switch listens to IGMP reports from receivers so it only forwards each multicast flow to ports that joined it—preventing “flooding” to every port.
  
  IGMPv3: Needed for Source-Specific Multicast (SSM) joins (the (S,G) style 2110 prefers). Make sure snooping is v3 on all VLANs carrying media.
  
  IGMP querier: On a pure Layer-2 VLAN, enable a querier (often the switch SVI or a small L3 gateway) so it periodically asks “who still wants this group?” Without a querier, snooping tables age out and traffic stops.
  
  Fast-leave (a.k.a. immediate-leave): When a receiver leaves a group, the switch immediately prunes that port instead of waiting for group-specific queries—reduces tail traffic and speeds zaps. Use where you expect rapid joins/leaves (multiviewers, control panels).
  
  Gotchas
  Enable snooping per VLAN; if there’s no querier on that VLAN, add one. Don’t run multiple queriers in one VLAN unless you’ve tested tie-break behavior. Verify with counters/table views: you should see per-port (S,G) state, not unknown-multicast floods.
  
  L3: PIM-SSM (Source-Specific Multicast)
  What it is: The multicast routing protocol so groups can cross subnets/routers. In SSM mode, receivers join (S,G) (“this source, this group”)—no Rendezvous Point needed.
  
  Why SSM for 2110: Predictable joins, no unwanted senders, simpler control plane, faster convergence.
  
  Config themes:
  • Turn on PIM-SSM on the routed interfaces that carry media VLANs.
  • Define the SSM range (commonly 232.0.0.0/8 for IPv4).
  • Ensure IGMPv3 at the edge so endpoints can request (S,G).
  • Unicast routing must be solid (PIM uses RPF checks to the S).

  Gotchas

  • If receivers only send (*,G) joins (IGMPv2), they won’t get SSM behavior—upgrade them or force IGMPv3.
  • RPF failures = no tree; fix unicast route to the source S (static/OSPF/BGP).
  • Keep TTL high enough for your hop count; some devices default to 1.

  Addressing: use 232/8 for SSM groups
  IPv4 SSM block: 232.0.0.0/8. Pick sub-ranges (e.g., 232.1.x.y) for video, audio, ANC, test, etc. Avoid the ASM ranges (e.g., 239/8) unless you truly need Any-Source Multicast.
  
  Document who owns which G; don’t reuse groups across different senders unless intended.
  
  Fast checklist / “known good” defaults
  Every media VLAN: IGMP snooping v3 = on; querier = on (or an L3 interface present); fast-leave = on for receiver-heavy VLANs.
  
  Routing layer: PIM-SSM enabled on all relevant L3 interfaces; SSM range = 232/8; unicast routing to all sources is correct.
  
  Endpoints: IGMPv3 capable; join (S,G) from control/NMOS (IS-05).
  
  QoS: Don’t forget DSCP on multicast media; keep PTP highest priority.
  
  How to spot it working
  Switch (L2) tables: You see (S,G) entries bound to only the ports where receivers live; leaving a group trims the port immediately (fast-leave).
  
  Router (L3) mroute table: Entries show (S,G) state with the incoming interface (toward S) and outgoing interfaces (toward receivers).
  
  Wireshark/pcap: Receiver sends IGMPv3 membership report specifying S and G; no ASM joins.
  
  If you tell me your switch/router platform, I can translate this into the exact commands and a minimal validation checklist for that OS.

---

6. MTU/fragmentation issues
• Symptom: Flows drop or stutter after path/LAG change.
• Fix: End-to-end MTU 9000 (9216 on switches) for media; keep PTP small; test with jumbo pings.
  
  MTU 9000 = “jumbo frames” so a single IP packet can carry ~9 KB of payload (vs the default 1500 B).
  
  9216 on switches = common max frame size that leaves headroom for L2/L3 headers (VLAN, QinQ, MACsec, etc.) so your 9 KB IP MTU won’t get chopped.
  
  Why do it? Far fewer packets per UHD stream → lower interrupt/CPU load, smoother pacing, and more headroom for 2022-7 (since you’re duplicating traffic on A/B).
  
  Golden rules
  End-to-end or don’t do it: every hop (NICs, server vSwitch, switch ports, LAGs, routers, firewalls, taps) must support the same MTU, or you’ll get silent drops/fragmentation.
  
  Keep PTP small : jumbo for media flows only; timing/control stay at standard MTU so they’re never blocked behind long packets.
  
  Mind serialization delay: jumbo frames take longer “on the wire”; give PTP strict priority (LLQ) so it jumps ahead of jumbo media at each hop.
  
  Typical config targets
  Hosts/NICs: MTU 9000 (Windows often shows 9014; Linux ip link set mtu 9000).
  
  Switches: 9216 max-frame (or vendor’s equivalent “system mtu jumbo 9216”), and set per-port/VLAN MTU if required by OS.
  
  Tunnels/overheads: If you use VLAN stacking, VXLAN, GRE, MACsec, raise switch max-frame accordingly; MACsec adds ~32 B, VXLAN adds ~50 B.
  
  Validation checklist (do this before turning up media)
  Path test (no frag):
  • Windows: ping -f -l 8972 <peer> (8972 payload + 28 IP/ICMP ≈ 9000).
  • Linux: ping -M do -s 8972 <peer>.
    Success end-to-end on both Red and Blue fabrics.
  Mirror through LAG/ECMP paths: Test every uplink bundle and routed path you’ll actually use.
  
  Span/Monitor: Ensure SPAN/TAP ports and monitoring gear can handle > 9000 if you mirror jumbo flows.
  
  Counters: Watch for giant frame drops, MTU/fragment counters anywhere in the path.
  
  Gotchas to avoid
  One-sided jumbo: If any hop is still 1500, jumbos get dropped or fragmented (UDP media hates frag).
  
  QoS mis-map: PTP must be CS6 → strict-priority; jumbo media in lower queues (e.g., CS5/AF41) so Sync/Follow_Up aren’t stuck behind 9 KB packets.
  
  Firewalls / IPS: Many inline devices default to 1500; either bypass or raise their max-frame.
  
  MACsec / VXLAN: Account for added bytes—keep switch max-frame ≥ MTU + all overhead.
  
  Roll-out pattern (safe)
  Enable 9216 system max-frame on the fabric (both Red/Blue).
  
  Set access/trunk port MTUs and L3 SVI/IRB MTUs to carry 9000 IP.
  
  Raise host NIC MTU last; validate with jumbo pings both directions.
  
  Turn up one sender/receiver; confirm no drops, then scale out.
  
  Why it helps 2110 specifically
  Fewer packets per 1080p/2160p flow → less per-packet overhead, better pacing against 2110-21 traffic-shaping.
  
  2022-7 uses 2× bandwidth; jumbo reduces packet rate on each leg, easing NIC and switch pipelines.
  
  Predictable buffering in switches/NICs reduces microburst drops during joins/zaps.
  
  Bottom line: Set media paths to 9000-byte IP MTU and switches to 9216 max frame, keep PTP/control at standard MTU with strict priority, and prove both fabrics with jumbo pings and drop-free counters before going live.
  
  LAG = Link Aggregation Group; two or more physical links bundled to act as one logical uplink/port-channel for more bandwidth and redundancy. A “LAG change” is any event that alters that bundle.

---

7. NIC/host not tuned for real-time
• Symptom: Drops on sender/receiver, DPC spikes.
• Fix: Enable HW timestamping; RSS on; LRO/RSC off for UDP; low interrupt moderation; High-Perf power plan; pin threads/NUMA.
  
  DPC spikes are bursts of time the Windows kernel spends running Deferred Procedure Calls (and related ISRs—interrupt service routines), which delay normal threads.
  
  In real-time workflows (ST 2110 send/receive, audio, video), big/erratic DPC latency causes packet drops, jitter, audio pops, and missed deadlines.
  
  Why it happens (common culprits)
  • Bad or busy drivers: NIC, GPU, storage, Wi-Fi/BT, audio, ACPI/chipset.
  • Aggressive power saving: deep C-states, CPU frequency scaling.
  • Heavy interrupt storms: poorly tuned NIC interrupt moderation, MSI/MSI-X issues.
  • Background security/telemetry filters on the network stack.
  How to spot it
  • LatencyMon: check “Highest DPC/ISR execution time” and culprit drivers.
  • Windows Performance Analyzer (WPA) / xperf: DPC/ISR CPU usage timeline.
  • Watch your 2110 app/NIC counters for missed/ooo packets aligning with latency spikes.
  Quick mitigations (2110-oriented)
  • Update/roll back NIC, GPU, storage, chipset drivers; pick known-good/LTS builds (e.g., stable WinOF-2 + recommended FW).
  • NIC tuning: enable RSS, set interrupt moderation low, disable LRO/RSC for UDP, keep HW timestamping on.
  • Power: High Performance plan; disable deepest C-states/core parking if allowed; lock min CPU freq higher. That is keep CPU cores “awake” and clocked predictably so DPC/ISR latency stays flat and your NIC/app threads hit their deadlines.
    • Use a performance-biased power plan
    • Windows UI: Settings → System → Power → Additional power settings → pick High performance (or Ultimate Performance on Pro/Workstation).
    • CLI (quick):
      :: enable Ultimate Performance if available
      powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61
      :: make High performance active (GUID may differ on your box)
      powercfg /S 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c
    • Lock minimum CPU frequency higher (reduce “downshift” latency)
    • UI path (when exposed): Control Panel → Power Options → Change plan settings → Advanced → Processor power management
      • Minimum processor state: 80–100% (start at 90%)
      • Maximum processor state: 100% (leave Turbo on unless thermals are an issue)
    • CLI (always works):
      :: AC (plugged-in) min processor state → 90%
      powercfg -setacvalueindex SCHEME_CURRENT SUB_PROCESSOR PROCTHROTTLEMIN 90
      :: DC (battery) if relevant → 60–80%
      powercfg -setdcvalueindex SCHEME_CURRENT SUB_PROCESSOR PROCTHROTTLEMIN 60
      powercfg -S SCHEME_CURRENT
    • Tame core parking (keep worker/IRQ cores available)
      Core parking parks whole cores under light load—great for battery life, bad for real-time.
    • Expose the hidden settings, then set to performance:
      :: Unhide processor performance core parking knobs
      powercfg -attributes SUB_PROCESSOR 0cc5b647-c1df-4637-891a-dec35c318583 -ATTRIB_HIDE
      powercfg -attributes SUB_PROCESSOR ea062031-0e34-4ff1-9b6d-eb1059334028 -ATTRIB_HIDE
      powercfg -attributes SUB_PROCESSOR 68F262A7-F621-4069-B9A5-4874169BE23C -ATTRIB_HIDE
      :: Set "Core parking min cores" to 100% (i.e., don't park)
      powercfg -setacvalueindex SCHEME_CURRENT SUB_PROCESSOR 0cc5b647-c1df-4637-891a-dec35c318583 100
      powercfg -setacvalueindex SCHEME_CURRENT SUB_PROCESSOR ea062031-0e34-4ff1-9b6d-eb1059334028 100
      powercfg -S SCHEME_CURRENT
      
      (Exact GUIDs vary by Windows build; if these don’t exist on your system, you can use a power-tuning tool or Group Policy.)
    • BIOS/UEFI: reduce deep sleep & frequency dithering
      These are platform-specific; look for:
    • C-states: Disable the deepest states (e.g., C6/C7) if allowed; keep C1E enabled for stability.
    • Intel: Set Speed Shift (HWP) EPP to “Performance” (low EPP value), keep Turbo enabled, disable “C-state demotion/promotion” only if you see jitter.
    • AMD: Use CPPC Preferred Cores on, Windows Balanced for AMD is fine—but for 2110 stick to a Performance plan; consider PBO off for determinism.
    • PCIe ASPM: Off (prevents link power-saves adding latency).
    • HPET/Timers: Avoid forcing HPET as sole system timer; let Windows choose (mixing HPET-only can increase latency on some systems).
    • NIC/driver alignment (power interacts with interrupts)
    • On your media NIC: Hardware Timestamping = On, RSS = On (enough queues to match active cores), Interrupt Moderation = Low, LRO/RSC = Off (UDP).
    Pin your 2110 app threads and NIC IRQs to the same NUMA node as the NIC (app setting or Affinity/processor groups).
    • Turn off “helpful” idle savers that add jitter
    • USB selective suspend: Off (for capture devices/control surfaces).
    PCI Express → Link State Power Management: Off. Wireless/Bluetooth (if unused): Disable the device—these drivers often spike DPCs. Background scanners: Exclude your media NIC/process from deep packet inspection or endpoint DLP.
    • Verify the effect (don’t skip)
    • LatencyMon: Watch Highest DPC/ISR execution time and culprit drivers—aim for consistent sub-millisecond, ideally sub-100 µs on tuned workstations.
    • Windows Performance Analyzer (WPA): DPC/ISR CPU usage over time while you run real traffic.
    • Your app/NIC counters: look for missed/OOO packets aligning with DPC spikes—if they vanish after tuning, you’re there.
    • Safe starting preset (works well for most 2110 PCs)
    • High/Ultimate Performance plan active.
    • Min proc state 90%, Max 100%.
    • Core parking effectively disabled.
      Core parking is a power-saving feature where the OS idles (“parks”) entire CPU cores during light load so fewer cores run faster while the parked ones sleep.
    • BIOS: Deep C-states off; Speed Shift EPP = Performance; ASPM off.
      Deep C-states are the low-power sleep modes a CPU can enter when it’s idle. The deeper the state, the more of the core (and sometimes its caches or even parts of the socket/package) is powered down—saving more energy but adding wake-up latency.
      EPP = Energy Performance Preference (Intel Speed Shift / HWP hint). When it’s set to Performance, the CPU gets a low EPP value (≈0–64 on a 0–255 scale), telling it to favor responsiveness and higher clocks over energy savings—i.e., quicker turbo, less aggressive down-clocking, and shallower idle states.
      ASPM = Active State Power Management for PCIe links. It saves power by dropping an idle PCIe link into low-power states
    • NIC: RSS on, HW TS on, LRO/RSC off, low interrupt moderation.
    • Validate with LatencyMon + a real 2110 send/receive test.
    Trade-off: you’ll burn more watts and run hotter. That’s the price of determinism—watch thermals and fan curves so you don’t throttle under load.
  • Remove noise: prefer wired NIC, disable unused Wi-Fi/BT/audio devices for tests.
  • Pin media threads/IRQs to the NIC’s NUMA node; avoid sharing that core with other heavy ISRs.
    NUMA stands for Non-Uniform Memory Access—a computer architecture where each CPU socket has its own local memory that it can access faster than memory attached to other sockets, so memory access time is “non-uniform” across the system.
  • Security/monitoring: exclude 2110 interfaces from packet inspection features.
  Rule of thumb: keep DPC/ISR latency consistently low and flat (sub-millisecond; often sub-100 µs for tight UHD paths), or real-time traffic will stutter.
8. 2022-7 mispaired or asymmetric
• Symptom: Hitless isn’t hitless; slips during failures.
• Fix: True independent Red/Blue (VRFs/VLANs/links); identical policies; adequate diff-delay buffer; prefer different ECMP paths.
  The differential-delay (diff-delay) buffer is the small receiver-side buffer that absorbs the timing difference between the two redundant legs (A and B) of the same RTP stream.
  ECMP (Equal-Cost Multi-Path) paths are multiple network routes to the same destination that all have the same routing cost/metric, letting routers/switches load-balance traffic across parallel links.
9. SDP/NMOS inconsistencies
• Symptom: Joins succeed but wrong payload/clocking; devices appear/disappear.
• Fix: Validate SDP (payload type, rates, TS offsets); stable IS-04 registry; correct IS-05 connection params.
  SDP (Session Description Protocol) is a small, text-based “connection card” (RFC 4566) that tells a receiver how to join and decode a media stream—IP/port(s), transport (RTP/UDP), codec/payload format, timing/clocking, and other
  parameters In ST 2110 workflows, SDP is what devices exchange (directly or via NMOS IS-05) so a receiver can subscribe to the right (S,G) multicast, use the correct RTP payload format (e.g., RFC 4175 video, AES67 audio), and lock timing to PTP/ST 2059.
  
  Typical SDP ingredients for 2110 c= / m= lines: network address and RTP port(s) (often a multicast group).
  a=rtpmap / a=fmtp: codec and format details (e.g., sampling, bit depth, resolution, channel count).
  a=source-filter: SSM source (ties to (S,G)).
  a=ts-refclk / a=mediaclk: how to reference PTP and media clocking.
  Direction (a=recvonly/sendonly), packetization, and ancillary attributes as needed.
  
  Mini example – 2110-20 (video) v=0
  o=- 0 0 IN IP4 10.10.0.10
  s=ST 2110-20 Video
  t=0 0
  m=video 50020 RTP/AVP 96
  c=IN IP4 232.1.2.20/64
  a=recvonly
  a=source-filter: incl IN IP4 232.1.2.20 10.10.0.10
  a=rtpmap:96 raw/90000
  a=fmtp:96 sampling=YCbCr-4:2:2;depth=10;width=3840;height=2160;exactframerate=60000/1001;interlace=0;transfer=BT709;colorimetry=BT709;PM=2110GPM
  a=ts-refclk:ptp=IEEE1588-2008:domain=127
  a=mediaclk:direct=0
  
  Bottom line: SDP is the machine-readable recipe that makes 2110 connections interoperable—your control layer (NMOS) points devices at each other, and SDP tells them exactly what to expect and how to stay in sync.
  .
10. Monitoring blind spots
• Symptom: “It breaks sometimes” with no clues.
• Fix: Stream telemetry (gNMI/JSON) for PTP (offset, delay, GM, steps), enable sFlow/NetFlow, watch per-queue drops, and keep readable PTP “show” outputs.
  gNMI/JSON = gRPC Network Management Interface (an OpenConfig standard) used to stream telemetry and manage config on switches/routers, with the data encoded as JSON (human-readable) instead of protobuf—so you can subscribe to live paths (e.g., PTP offset, queue counters, (S,G) tables) and receive near-real-time updates over a secure gRPC channel.
  sFlow: Packet/header sampling. The switch/router samples, say, 1 in N packets (plus counters) and exports those sampled headers to a collector. Great for seeing “who’s talking to whom,” burstiness, DSCP classes, and quick anomaly detection with low device overhead.
  NetFlow / IPFIX: Flow records. The device summarizes each flow (5-tuple, bytes, packets, duration, DSCP, etc.) and periodically exports a record—no packet payloads, just metadata. Excellent for bandwidth accounting, top talkers, and proving multicast joins/receivers over time.
  2110 tip: use sFlow to visualize real-time (S,G) traffic and QoS classes during zaps, and NetFlow/IPFIX to audit sustained bandwidth per flow/receiver; keep PTP queues excluded from any heavy export that could add jitter.

Quick golden defaults:
One PTP domain (e.g., 127), P2P TC for small L2 or BC at agg/leaf for scale.
PTP = CS6 → LLQ; media = CS5/AF41; control lower.
IGMPv3 + SSM 232/8, MTU 9000, 2022-7 Red/Blue truly independent.
Validate WinOF-2/driver/firmware combos on NICs; verify with Wireshark and per-queue counters.

Host/NIC & servo

• PTP client bound to the media NIC; hardware timestamping enabled.
• Disable other timekeepers (NTP/W32Time) while testing.
• NTP (Network Time Protocol) is the standard internet protocol for keeping computers’ clocks in sync with time servers, usually to the millisecond range.
• W32Time (Windows Time Service) is Windows’ built-in time client/server that can use NTP (and domain time in Active Directory) to set the Windows system clock.
• In 2110/PTP plants: if a host is disciplined by PTP for media timing, you typically disable or isolate W32Time/NTP on that interface so it doesn’t “fight” the PTP servo; if you still need wall-clock for logs, point W32Time to a PTP-to-NTP gateway or keep it on a management NIC.
• Servo states: should go Acquisition → Tracking; if stuck, look at:
• offsetFromMaster huge or noisy → suspect QoS/queueing or asymmetry.
• meanPathDelay unstable with load → PTP is queuing behind media.
• Slew-limit hits constantly → loop too “stiff” for your oscillator;
increase Sync rate or widen loop bandwidth cautiously.

Must Match Checklist

domainNumber: identical across GM, BC/TC, endpoints.
delay mechanism: all E2E or all P2P.
timestamp style: all one-step or all two-step.

• Two-step: The master sends a Sync first (without the final precise TX timestamp), then immediately sends a Follow_Up that carries the exact hardware timestamp and any accumulated correctionField. Slaves pair the two by sequence ID. Universally supported; doesn’t need in-flight rewrite; easier for mixed hardware. Requires one extra Follow_Up per Sync; receivers must stitch Sync↔Follow_Up.
• One-step: The master edits the Sync on the fly at the egress port to insert the final hardware timestamp (and updated correctionField) right into that single packet—no Follow_Up needed. Fewer packets; simpler on receivers; slightly lower control-plane load. Requires capable silicon on GM/BC/TC to modify frames in flight; mixed vendors sometimes have quirks.
• The true send time isn’t known until the frame physically leaves the NIC/ASIC.
  If the device can rewrite the packet at egress → one-step works.
  If it can’t rewrite → it must send the time later → two-step.

Profile: ST 2059 values (logSyncInterval, logAnnounceInterval, delay intervals) consistent.

• logSyncInterval – How often the master sends Sync (and Follow_Up if two-step).
  Value is a power of two: interval = 2^logSyncInterval seconds (e.g., −3 → 1/8 s = 125 ms, 0 → 1 s).
• logAnnounceInterval – How often a clock sends Announce (used by BMCA to elect the GM).
  Same math: 2^logAnnounceInterval seconds (common: 0 → 1 s).
• Delay intervals – How often path delay is measured:
• logMinDelayReqInterval (E2E): slave sends Delay_Req every 2^value seconds (e.g., 0 → 1 s, −1 → 0.5 s).
• logPdelayReqInterval (P2P): peers exchange Pdelay_Req/Resp per-link every 2^value seconds (typical 0 or −1).

 Rule of thumb: faster (more negative) intervals improve tracking on noisy/asymmetric networks but add control traffic;
 pick rates your switches/NICs handle comfortably and give PTP strict QoS.

QoS

Congestion checks

• DSCP of PTP = CS6 (or your plant’s highest).
• DSCP→queue map: PTP in strict-priority/LLQ on every port.
• Per-queue counters: zero drops in the PTP class, tiny average depth.
  A DSCP→queue map is the switch’s lookup table that says, “packets marked with this DSCP value go into that hardware egress queue (with a given priority/behavior).”
  
  

  Tiny example (typical 2110 plant):
  PTP = DSCP CS6 (48) → Queue 7 (strict priority / LLQ)
  2110 media = CS5 (40) or AF41 (34) → Queue 5 (high, shaped)
  Control/Discovery (NMOS, APIs) = CS3/CS2 (24/16) → Queue 3/2
  Best-effort = CS0 (0) → Queue 0

  In QoS, “queue values” are just the hardware egress queues on a switch/NIC port—usually numbered (e.g., 0–7)—that the scheduler services with different priority/behavior. Each port has multiple FIFO queues. Packets are classified (by DSCP/CoS/ACL) and enqueued into one of them.

  LLQ (Low-Latency Queuing) is a QoS feature that gives certain traffic a strict-priority queue so it’s sent immediately ahead of other queues—ideal for timing (PTP) or voice/video control packets.
  
  Key notes: it minimizes jitter/latency, but you must police/shape the priority class (and keep it small) so it doesn’t starve the rest of the traffic.



• No shaping/policing on PTP; keep jumbo media out of the top queue.
  PTP starved by jumbo traffic → fix DSCP mapping; put PTP in strict queue.

Red/Blue issues

• Both fabrics must carry the same domain and healthy PTP.
• If only Red locks, Blue likely has IGMP/ACL/QoS or GM reachability issue.
• Keep optics/link types symmetric to avoid asymmetry in one leg.

Timing

Grandmaster

• BMCA picks a bad peer as GM (priority1/2 wrong).
  Wrong BMCA priorities → set real GM priority1 lowest (best), raise others.
• Multiple GMs with similar priority → flapping identity.
• Real GM’s clockClass not healthy (e.g., 7/248), so slaves refuse to follow.

On a switch/endpoint PTP status page:

• Announce messages incrementing?
• GM identity stable?
• clockClass good (e.g., 6 when GNSS-locked)?
• stepsRemoved reasonable (≤3 typical).
• If you see no Announces/Syncs → routing/IGMP/VLAN/ACL problem.

Delay mismatch: plant is E2E, device is P2P (or vice-versa).
Domain mismatch (device on 0, plant on 127).
Host/NIC not timestamping: HW timestamping disabled or wrong NIC bound to the PTP client. Another time service (NTP/W32Time) fighting the PTP servo.

PTP

• PTP packets aren’t making it
• IGMP/Multicast blocked, wrong VLAN, or ACL denying UDP/319,320.
• QoS puts PTP behind jumbo media → Sync/Fup/Delay starved; meanPathDelay wanders.
• One-step vs two-step mismatch between GM/BC/TC/NICs.
• Filter: udp.port == 319 or udp.port == 320
  Permit UDP/319,320 and any unicast PTP control flows.
• Sync cadence steady (e.g., every 125 ms or 1 s)?
• Two-step: each Sync has a matching Follow_Up (same sequenceId).
• correctionField grows across TCs (not zero on every hop).
• Multicast groups correct (e.g., 224.0.1.129 for default PTPv2)? If unicast-PTP is used, verify that handshake.
• Boundary Clock nodes: each BC should be SLAVE upstream and MASTER downstream; watch stepsRemoved and announce/sync intervals through the chain.